>MI^L 48 in memory 40 on central process^^ 



I 39a-39n search PMI^Be 48 in memory 40 on central processBri2 for a match with 
their line card type and version number. Just as the master MCD 36 found the name 
)f the MKI executable file for each line card in the PMD file, each slave MCD 39a- 
iKW 1 3 2000 23 9n reads the PMD file to learn the names of all the device driver executable files 
^associated with each line card type and version. The slave MCDs provide these 
— names to the slave SRMs on their boards. Slave SRMs 37a-37n then download and 
execute the device driver executable files (DD.exe) 56a-56n from memory 40. As 
one example, one port device driver 43a-43d may be started for each port 44a-44d on 
line card 16a. The port driver and port are linked together through the assigned port 
/OPID number. 
H 

In order to understand the significance of the PMD file (i.e., metadata), note that the 
MCD software does not have knowledge of board types built into it. Instead, the 
MCD parameterizes its operations on a particular board by looking up the card type 
ind version number in the PMD file and acting accordingly. Consequently, the MCD 
software does not need to be modified, rebuilt, tested and distributed with new 
hardware. The changes required in the software system infrastructure to support new 
hardware are simpler modify logical model 280 (Fig. 3) to include: a new entry in the 
PMD file (or a new PMD file) and, where necessary, new device drivers and 
20 applications. Because the MCD software, which resides in the kernel, will not need to 
be modified, the new applications and device drivers and the new DDL files 
(reflecting the new PMD file) for the configuration database and NMS database are 
downloaded and upgraded (as described below) without re-booting the computer 
system. 

Z(s> Network Management System (NMS): 

Referring to Fig. 9, a user of computer system 10 works with network management 
system (NMS) software 60 to configure computer system 10. In the embodiment 
described below, NMS 60 runs on a personal computer or workstation 62 and 
?>0 communicates with central processor 12 over Ethernet networl^^(out-of-band). 
Instead, the NMS may communicate with central processor 12 over data path 34 (Fig. 
1, in-band). Alternatively (or in addition as a back-up communication port), a user 
may communicate with computer system 10 through a terminal connected to a serial 
line 66 connecting to the data or control path using a command line interface (CLI) 
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/ protocol. Instead, nM> 60 could run directly on computer syWm 10 provided 
computer system 10 has an input mechanism for the user. 

NMS 60 establishes an NMS database 61 on work station 62 using a DDL file 
5 corresponding to the NMS database and downloaded from persistent storage 21 in 
computer system 10. The NMS database mirrors the configuration database through 
an active query feature (described below). In one embodiment, the NMS database is 
an Oracle database from Oracle Corporation in Boston, Massachusetts. The NMS and 



^ central processor 12 pass control and data over Ethernet^ using, for example, the 



10 Java Database Connectivity (JDBC) protocol. Use of the JDBC protocol allows the 
NMS to communicate with the configuration database in the same manner that it 
communicates with its own internal storage mechanisms, including the NMS 
database. Changes made to the configuration database are passed to the NMS 
database to insure that both databases store the same data. This synchronization 
process is much more efficient and timely than older methods that require the NMS to 
periodically poll the network device to determine whether configuration changes have 
been made. In these systems, NMS polling is unnecessary and wasteful if the 
configuration has not been changed. Additionally, if a configuration change is made 
through some other means, for example, a command line interface, and not through 
the NMS, the NMS will not be updated until the next poll, and if the network device 
crashes prior to the NMS poll, then the configuration change will be lost. In computer 
system 10, however, command line interface changes made to configuration database 
42 are passed immediately to the NMS database through the active query feature 
ensuring that the NMS is immediately aware of any configuration changes. 

Typically, work station 62 is coupled to many network computer systems, and NMS 
60 is used to configure and manage each of these systems. In addition to configuring 
each system, the NMS also interprets data gathered by each system relevant to each 
system's network accounting data, statistics, and fault logging and presents this to the 
user. Instead of having the NMS interpret each system's data in the same fashion, 
flexibility is added by having each system send the NMS a JAVA class file 410 
indicating how its network data should be interpreted. Through the File Transfer 
Protocol (ftp), an accounting subsystem process 412 running on central processor 12 
pushes a data summary file 414 and a binary data file 416 to the NMS. The data 
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